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Abstract 

This work proposes an extension of classical network 
management protocols such as SNMP (Simple Network 
Management Protocols) for a deep test and management of 
network electronic components such as routers, switches 
and PCs. To this end, the proposed approach starts very 
early in the design process of the integrated circuits that 
are used in the construction of the managed agents. The 
approach is based on an extension of design-for-test 
technique. The approach is described and its efficiency is 
illustrated through extensive experimentations. 

Keywords: Network management, SNMP Protocol, 
. System-on-Chip (SoC), Design-For-Test, P1500 Wrapper. 



1. Introduction 

Network management becomes mandatory for 
corporation intranet and extranet- However, there is no 
mechanism today that allows the management of the 
electronic components that compose each managed node. 
Indeed, given a TCP/IP network, it is useful to manage not 
only basic nodes (PCs, routers, terminal servers, ...) but 
also the electronics, i.e. the integrated circuits which 
compose such nodes. This can critical for maintenance and 
on-line testing purposes. This can be made possible if and 
only if the electronics supports testing and maintenance 
facilities. 

Design-For-Test (OFT) techniques consist in 
integrating testability features at the design stage of 
electronic components. Such techniques become 
mandatory for production testing of today integrated 
circuits and systems. Among the widely used DFT 
techniques there is the IEEE standard called PI 500 [1,2,3]. 
It improves the testability (controllability and 
observability) of System-on-Chip (SoC) by adding more 
logic. None of these techniques has been considered to 
facilitate the maintainability and the management of 
electronic systems (e.g. routers, switches) that belong to a 
managed TCP/IP network. This work shows how to take 



benefit from the PI 500 DFT technique by extending the 
necessary logic and make is usable by the SNMP (Simple 
Network Management Protocol) management protocol. 

A SoC which composes a networking device embeds 
hundreds of million of transistors. Such a huge amount of 
transistors within a single chip makes possible the 
implementation of complex functionalities for signal 
processing, calculation, memorizing, etc.. Designing a SoC 
is mainly based on the use or the reuse of Intellectual 
Proprieties (IP) such as processor RISC, DSP, RAM and 
ROM [4]. Testing is a critical issue in the development and 
production process of SoC. 

The proposed approach in this paper enhances the 
accessibility to IP Cores, given a complex SoC. It takes 
advantage of SNMP which was originally proposed to 
enhance the management of TCP/IP local area networks, 
within a SoC for a better testability of all IP Cores and 
consequently of all SoCs which constitute the electronis 
system. Indeed, PI 500 facilitates the access to the internal 
structure of an IP Core and the transfer of the information 
of test between the provider and the IP Core integrator. 
SNMP was originally suggested by the IETF []. Known as 
simple and very efficient, SNMP embeds a set of 
functionalities that allow the management of 
heterogeneous and complex networks. In this work, SNMP 
is considered beyond the classical framework of network 
management because it is implemented within a SoC. 

An SNMP-based network (fig. 1) consists of several 
components [5,6]: a Network Management Station (NMS), 
a Network element (NE)> a database called MIB 
(Management Information Base) and the SNMP protocol. 
Trie MIB is a collection of objects stored into an 
information virtual base. An SNMP agent is a NE. It seeks 
network information such as the number of erroneous 
packets and sends them to the NMS. 

Main motivations of using SNMP as a backbone of a 
testing strategy are summarized as follows: 

• Management and monitoring of the activity of 
various electronic equipments that are widely used 
in local networks (computer, router, switch, etc.), 

• Collecting of deep state information on the state of 
each component, 

• Detection of network failures, 
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Elaboration of a standard management as regards to 
remote access to information base (MIE), 
Take benefit from available network management 
software tools such as HPOPENVIEW of Hewlett- 
Packard. 
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Fig. 1: SNMP environment 

More precisely, using the proposed approach, each IP 
Core with a SoC behaves as an SNMP agent. It is 
noteworthy that PI 500 has been considered for the 
following reasons: (1) it helps in the isolation of an IP 
Core among those that compose the SoC, (2) it provides a 
standard mechanism of access to internal logic, (3) it 
facilitates the mix and the interconnection of IP Cores 
which are provided from multiple vendors, (4) it is an 
IEEE standard widely spread and well documented. 

This paper is organized as follows. Section 2 presents 
testing challenges of SoCs in the framework of the 
proposed approach. Section 3 presents the SNMP 
compliant testing architecture. Section 4 describes the 
details of extended PI 500 architecture. Finally, simulation 
results are presented before concluding this paper. 

2. SoC testing 

The new design methodology of SOCs raises new 
testing problems [1,3,4]. Indeed, testing today integrated 
circuits involves the responsibility of not only the device 
manufacturer but also the designer and the IP Core 
provider. 

An IP Core is tested by the core integrator as a part of a 
SoC. This is accomplished by using test vectors that are 
given by the IP Core provider. Indeed, the integrator of a 
SoC has few information on the used IP Core. IP Cores are 
considered as black boxes. Today, more than ever an IP 
Core has to be designed with testability issues in mind [4]: 
test point insertion, Scan, BIST insertion, etc. 
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Hence, the problem of SoC testing requires new 
challenges [1]: 

• The transfer of an IP Core testing information from 
the designer to the user, 

• The access to a testing IP Core infrastructure, so as 
to be able to reach inputs/outputs and to connect 
them to an A TE (Automatic Test Equipment) or to a 
SoC logic BIST. 

• The optimization of test integration to ensure a 
good trade-off performance/cost. 

Beyond testing, another problem comes from the 
diversity of the origin and the technology of IP Cores. 
Indeed, the IP Cores are heterogeneous from several point 
of views: the used communication protocols, the used bus 
interface, frequency, etc. Such heterogeneous parameters 
imply connection and communication problems between 
the IP Cores. Thus, flexibility and compatibility are more 
than required by IP Core users. 

Many test standards have been proposed to make SoC 
testing an easier and less complex problem, in particular 
the PI 500 IEEE standard [1,2,3]. Thus, the consortium VSI 
(?) alliance [7] insists on the intensive acceleration of the 
SoC development by specifying standards facilitating the 
mixture and the interconnection of IP Core coming from 
multiple sources. It also recommends the transfer of the 
test information between the provider and the integrator. 

For test needs, each IP Core must be encapsulated in a 
PI 500 wrapper. The role of the wrapper is to allow the 
control of external inputs and to observe external outputs 
of the IP Core by means of a peripheral scan-path. In 
addition, the wrapper must allow the control of the IP 
Core's internal scan-path. It also makes possible to define 
the operating mode of the IP Core such as the functional 
mode/peripheral shift mode/internal shift mode, etc. So 
that tests information is disseminated within the SoC 
through a test access mechanism (TAM: test bus). 

An hybrid approach which combines classical DFT 
and SNMP has several advantages as surnmarized below: 
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Fig. 2: SoC testing by an ATE 

Minimization production testing costs; current 
testers known as ATEs (Automatic Test 
Equipments) are very expensive. The fact of 
carrying out test patterns on a remote SoC via a 
TCP/IP network (pre-installed) allows using less 
ATEs since each one of them can be used for 
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several tests. This is made possible since data can 
be carried out from an A TE to an electronic device 
through a classical TCP/IP network technology 
(see Figure 2). 

• Improving fault diagnosis: the access to test 
information [MIS) for each individual IP Core 
helps in the diagnosis of a SoC internal state. This 
is ensured through SNMP basic instructors such as 
SetRequest, GetRequest, GetNextRequest, 
GetBulkRequest and GetResponse []. 

• Better maintainability: using the proposed DFT 
approach makes possible the supervision of the 
activity of different SoC's IP. This allows taking 
advantage from the important asset in 
management network domain. Hence, the overall 
system maintainability is improved. 

3. Test architecture 

At the architecture level, a SoC is considered as 
embedded distributed system within an electronic 
device/system The IP Cores are SNMP agents that are 
interconnected by the means of a bus or a complex 
communication network. This infrastructure is managed 
starting from a network management station (fig. 3). 



SNMP/>Qent 
Managed by proxy 
agent 




management station 

(ATEl^v^sr' Get and Set Request Variables MIB 
v * i Response : Variables MIB 




SNMP interface 



PROXY Agent 



extended 
Wrapper P150C 



E*3 



I 




extend' 
Wrapper P150C 

DEI 



System Bus(TAM) 



extended 



Wrapper P150C 

El 



tL4 




extended 
Wrapper P150C 



El 



Fig. 3: Test Architecture 

The concept of proxy agent is an SNMP agent 
implemented by an embedded micro-controller (fig. 3), It 
synchronizes the IP Core testing. Indeed, it can be 
considered as an IP Core that gets SNMP requests (such as 
GetRequest, GetNextRequest, GetBulkRequest, SetRequest, 
etc.) coming from the station management (or ATE: 
Automatic Equipment Test). These requests are converted 
towards instructions in conformity with the extended 
PI 500 standard. Furthermore, the proxy agent analyzes the 
answers generated by IP Cores. Such answers are SNMP 
requests (GetResponse or Trap). Finally, test results are 
sent to the ATE as SNMP requests. It is noteworthy that the 
MIB of a proxy agent contains all test results that are 
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related to a SoC. Consequently, each IP Core stores a MIB 
that represents the behavior of the core. 

4. Extended wrapper PI 500 

Figure 4 shows the structure of the MIB. A MIB 
describes the functionalities of the test techniques 
associated with PI 500 Wrapper as well as information 
relating to the testing process (e.g. test vectors, test results) 
within an IP I SoC. 

This MIB is divided in two parts of information: the 
So C level information and the IP Cores level information. 
The first part is dedicated mainly to the SoC level 
information such as the SoC identifier, the cartography 
information, etc... The second part is dedicated only to IP 
Cores information tests. In this part, we find the 
information related to PI500 test architecture for each 
IP Cores regrouped in the table called 
IPCoresWrappedP1500Table". The index of this table is 
IPCorefndex" that represents the address of IP Cores in 
the SoC environment. We can also integrate other test 
architectures to this MIB such as IEEE 1 1 49. 1 standard if 
the IP Cores are wrapped with IEEE 1 1 49. 1 architecture. 

4.1 Extended PI 500 wrapper Architecture 

Figure 5 shows the architecture of the extended 
wrapper PI 500. This extension implements a large part of 
the MIB (fig. 4). The architecture of the extended wrapper 
PI 500 contains the following blocks: 
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Fig. 5: Extended wrapper P1500 
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TECTEST: a 4 bits register that identifies the 
used test technique (i.e. scan, BIST...). 
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Fig. 4: MIB of test architecture 
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• WBY, WBR, WSI, WSO, BIST, WIP: basic 
blocks which are already defined by the PI500 
standard [2]. Please refer to [1,2,3,4] for more 
information, 

• WIR (Wrapper Instruction Register) 
Extended: this logical block extends the classical 
P1500 instruction register in order to support 
SNMP instructions. Indeed, new instructions are 
necessary for the extended architecture. 

• OID (Object EDentifier) register: this register 
gets a flatten object identifier from proxy agent. It 
completes the semantic of the added PI 500 
instructions. 

4.2 SNMP/P1500 relationship 

The relationship between SNMP instructions and 
those of PI 500 (see table 3) is implemented as proxy agent 
level. 

At SoC level, the control block (proxy agent) converts 
the SNMP requests into PI 500 instructions. For example, 
the SNMP request "GetRequest X.1. 1.1.0" is converted 
into WS__GETREQUEST PI 500 instruction with flatten 
Object IDentifier (OID) equal I. This value of flatten OID 
corresponds to hierarchical OID "X.1 .1.1.0". We use the 
flatten OID inside the SoC instead of hierarchical OID in 
order to miniinize the logic of treatment of hierarchical 
OID for each IP Cores. 



Tab. 1: Relationship between instructions 



SNMP request 


P1500 Instruction 


GetRequest X.1. 1.1.0 


WS_GETREQUEST with OID <= 1 
o to recovery of the contents of 
the register IDSOC which is at 
proxy agent level. 


GetRequest 

X.2.2. 1.2. IPCorelndex 


WS — GETREQUEST with OID <= 6 
o recovery of the contents of the 
register IDIP of IP selected. 


SetRequest 
X.2.2. 1.1.1 VT 


WS_SETREQUEST with OID<=15 
e> to start the functional test. 


SetRequest 

X.2.2. 1.4.IPCorelndex VT 


WS_SETREQUEST with OID<=20 
to start the external test. 


SetRequest 

X.2.2. 1.5.IPCorelndex VT 


WS_SETREQUEST with OID<=25 
o to start the internal test. 


SetRequest 

X.2.2.1.6.IPCorelndex VT 


WS_SETREQUEST with OID<=30 
o to start the internal test 
concatenating the WBR with scan 
chain. 


SetRequest 

X.2.2.1.7.IPCorelndex VT 


WS_SETREQUEST with OID<=35 
o to start the integrated test 
(BISn 


GetNextRequest @IP 
OID 


WS — GETNEXTREQUEST with the 
OID: the following O/O will be 
calculated starting from the 
received O/O. 



SNMP/P1500 



5. Experimental results 

Several experimentations have been carried out using 
twenty-two benchmarks known as ITC99 benchmarks [] . 
The obtained results are summarized in Figures 5 and 6. 
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Fig. 5: Area Overhead of the extended P1500 

interface 
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Fig. 6: Total area occupied by Wrapper according 
to the number of input/output of IPs 

As show in the above figures, the area is not affected 
by the proposed architecture. This is also illustrated in 
Figure 7 which gives the area overhead, the percentage of 
the area occupied by the extended wrapper compared to the 
total area of the IP Core. Indeed, for a complex IP Core, a 
SNMP interface necessitates a few added logic. 




I I T ■ I I i I I » 1 1 1 1 

1000 1500 2000 

IP+Wrapper area (urn 2 ) 



2500 



6. 



71247-16 prov app spec 
SLC/AMD 
02/1 6/04 

Fig. 7: Area overhead (%) using a SNMP 

interface 

Conclusion 



In this paper, a new approach that takes advantages of 
design-for-test of integrated circuits to enhance network 
management was presented. The approach is based on a 
combination between a simple network management 
protocol (SNMP) and the PI 500 design-for-test standard. 
The approach was shown cost-effective on several 
benchmarks. In future research, the approach will be 
experimented in a real TCP/IP network. 
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Complements 

La conception des circuits integres a beaucoup evoluee 
depuis quelques annees. Les progres tres importants de 
P integration des circuits a permis d'elaborer des circuits 
qui sont de reels systemes sur puce (SOC : System on 
Chip). La conception d'un SoC se base en grande partie sur 
l'utilisation des proprtetes intellectuelles (IP). Un IP 
correspond a un circuit ou un bloc preconcu d'un circuit. 
L'utilisation des IP dans la conception des SoC permet 
d'ecourter considerablement le temps d' apparition d'un 
circuit sur le marche (ttm : time-to-market). En revanche, 
les fournisseurs des IP ne fournissent pas les solutions de 
test qui 1'accompagnent. Par ailleurs, une fois le SoC 
concu, aucune solution ne permet de completement et 
d'une maniere efficace tester le circuit final. 

La presente invention vise 1'amelioration de testability des 
IP et SoC en se basant sur une technologie « reseaux » 
TCP/IP sans qu'il faille conciderer ce protocole comme le 
seul utilisable au sens de 1' invention. L'objectif est de 
rendre accessible a distance un SoC dans son ensemble 
et/ou un, plusieurs ou tous blocs fonctionnels constituant 
ledit SoC individuellement. 

Une telle possibilite d'acceder aux circuits en utilisant une 
technologie TCP/IP permet d'effectuer des tests a distance 
pour un but de partage de ressources couteuses comme les 
testeurs de circuits ou ATE (Automatic Test Equipements) 
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ainsi que d' assurer un test preventif ou de maintenance 
d'un systeme electronique complexe, 

L' approche de "conception testable" ou "Design-For-Test" 
au niveau des proprtetes intellectuelles et systemes sur 
puce permet d'acc^der aux information de test (vecteurs de 
tests, r&uitats de test) ainsi que d'activer des tests effectifs 
sur la puce et ceci a travers une techno logie rgseaux 
TCP/IP basee sur les protocoles d'administration tels que 
par exemple mais non exclusivement SNMP (Simple 
Network Management Protocol). 

11 doit §tre remarquS que cette approche de DFT au niveau 
des blocs ou IP a 6te decrite en relation avec la norme 
PI 500 sans quMl faille considerer que ce soit le seul moyen 
d'atteindre Pobjectif de l'invention . 
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